1.4.1. Basic Timezone Support

Support for the basic VTIMEZONE component and properties seemed to be fairly complete, with most vendors both consuming and producing such components. Note that “producing” a VTIMEZONE component usually means copying a component out of a standard library provided in the product. We are not aware of any iCalendar products that generate VTIMEZONE components on-the-fly from some other data source.

It was clear that a number of products prefer to operate in UTC and will “downgrade” DATE-TIME values to UTC if a timezone was included.

Most products include a built-in set of timezone definitions, ranging in number from 50 to 380. These came from a variety of different sources, including the Olsen timezone database, timezone information built into OS’s (e.g. Windows), those provided with other environments (Java). The naming of these components usually followed the scheme of the original data source. In one case a private namespace was used for timezone names.

Only 1/3 of products provide a way to update the built-in timezone via some automated process.

Only 1/4 of products were able to adjust future events, tasks etc when a timezone definition changed.

About 2/3 products would take in timezone definitions from outside sources. A number of products would attempt to match an “external” definition to the builtin ones and substitute any matching built-in definition in place of the “external” one.